FIG. 1 is an overview of an evolved packet system, EPS, architecture 100 comprising evolved packet core, EPC, and a number of radio access networks connected to the EPC, as defined in specification 3rd Generation Partnership Program, 3GPP, TS 23.401. To this core network, different 3GPP defined access networks may be connected, such as an Evolved Universal Mobile Telecommunication System, UMTS, Terrestrial Radio Access Network, E-UTRAN 150, a UTRAN 160 and a GSM Edge Radio Access Network, GERAN 170. The radio access networks GERAN, UTRAN and E-UTRAN each comprises a number of base stations: base transceiver stations, BTS, nodeBs and eNodeBs, respectively (not shown) to which a user equipment, UE 120 may be connected. In addition, GERAN and UTRAN comprise also radio access network controllers: base station controllers, BSC, and radio network controllers, RNC, respectively (not shown). The UE 120 may be any kind of device that is enabled to be wirelessly connected via a 3GPP access network such as the E-UTRAN 150, the UTRAN 160 or the GERAN 170, such as a mobile phone, laptop etc. The EPC comprises a Mobility Management Entity, MME 102 connected to the E-UTRAN, a Serving Gateway, SGW 104 connected to the E-UTRAN, the MME and the UTRAN. The EPC further comprises a Packet Data Network, PDN, gateway, PGW 110 connected to the SGW, and a Policy Charging and Rules Function, PCRF 108, which functions as a policy controller, connected to the PGW. Further, to the PGW 110 and the PCRF 108 a packet data network 112 may be connected over which one or more operators' IP services may be provided to UEs via the EPC and the 3GPP access networks.
FIG. 2 shows an extension to the EPS architecture in order to allow also non-3GPP accesses. The extension is specified in 3GPP TS 23.402. In a non-3GPP network the radio interface is not specified by the 3GPP. An example of a non-3GPP network is WLAN. In the figure, some functionality belongs to the 3GPP network whereas some belong to the non-3GPP network. In FIG. 2, the 3GPP network may be a Home Public Land Mobile Network, HPLMN for the UE 120. The HPLMN may identify the PLMN, Public Land Mobile Network, in which the profile (also known as the subscription) of the subscriber owning the UE is held.
A non-3GPP access network may be trusted or untrusted. The exact definition of trusted or untrusted is given in the 3GPP specifications. Simplified, one can say that a trusted access network 180 is managed by an operator, e.g. an operator hotspot that is also managing the HPLMN or an operator that in some way co-operates with the HPLMN operator, whereas an untrusted access network 190 is not managed by the operator, e.g. a WiFi access point at home. For the non-3GPP access network, a security gateway called evolved Packet Data Gateway, ePDG 130 is used between the untrusted access network 190 and the 3GPP network. The UE 120 is arranged to set up a secure tunnel to the ePDG, and between the ePDG 130 and the PGW 110 there is an S2b interface. A trusted 3GPP access network 180 hosts a gateway, e.g. a Trusted Wireless Access Gateway, TWAG 185, defined in 3GPP TS 23.402 section 16. There is a point-to-point interface between the UE and the TWAG, and between the TWAG 185 and the PGW 110 there is an S2a interface.
3GPP defines the concept of a Packet Data Network, PDN. A PDN is in most cases an IP network, e.g. the Internet or an operator IP-based Multimedia Services, IMS, service network. A PDN has one or more names; each name is defined in a string called Access Point Name, APN. The PGW 110 is a gateway towards one or more PDNs. A UE may have one or more PDN connections. A PDN connection is a logical IP tunnel between the UE and the PGW, providing the UE access to a PDN. The setup of a PDN connection is initiated from the UE. Each PDN connection has a single IP address or prefix.
PDN connections can be setup over a 3GPP access or over a non-3GPP access. A UE may have one or more PDN connections over a 3GPP access, or one or more PDN connections over a non-3GPP access, or both simultaneously. Every PDN connection comprises one or more bearers. A bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and the PGW. Each bearer on a particular access has a unique bearer ID. The bearer IDs assigned for a specific UE on S2a/S2b are independent of the bearer IDs assigned for the same UE on S5 and may overlap in value. S5 is the 3GPP-interface between the PDN gateway 110 and the Serving gateway 104.
On the 3GPP access, the bearer is end-to-end between the UE and the PGW 110. The bearer ID is known by the PGW, the MME 102, the eNodeB and the UE 120. On the non-3GPP access, there is no bearer concept between the UE and the TWAG/ePDG. The bearer concept is only defined between the PGW and the TWAG/ePDG; i.e. it is only defined over S2a/S2b. In this case, the bearer ID is known by the PGW and the TWAG/ePDG but not by the UE. Regardless of access type, the PCRF 108 is not aware of bearer IDs. Every PDN connection has at least one bearer and this bearer is called the default bearer. All additional bearers on the PDN connection are called dedicated bearers.
A bearer carries traffic in the form of IP packets. Which traffic is carried on a bearer is defined by filters. A filter is an n-tuple where each element in the tuple contains a value, a range, or a wildcard. An n-tuple is also known as an IP flow. An example of a 5-tuple is: [dst IP=83.50.20.110, src IP=145.45.68.201, dst port=80, src port=*, prot=TCP]. This 5-tuple defines a source and destination IP address, a source and destination port, and a protocol. The source port is a wildcard. Traffic matching this 5-tuple filter would be all TCP traffic from IP address 145.45.68.201 to IP address 83.50.20.110 and destination port 80. A traffic flow template, TFT, contains one or more filters. Every bearer has a TFT. One bearer within a PDN connection and access may lack an explicit TFT, this bearer is typically the default bearer. Implicitly, such a bearer has a TFT with a single filter matching all packets.
IFOM is defined in 3GPP TS 23.402 and stands for IP flow mobility. An IFOM PDN connection is a special PDN connection that still has a single IP address/prefix but is routed over multiple accesses simultaneously. The UE and the PGW negotiate which IP flow that gets routed over which access. Even though an IFOM PDN connection may be routed over multiple accesses simultaneously, the bearers on each access within that PDN connection are independent of each other. In order to negotiate which IP flow shall be routed over which access, routing rule update procedures are being defined. A routing rule update can be initiated either from the UE or from the PGW. Exemplary call flows for network-initiated routing rule update procedures for S2a can be found in “Network-initiated IFOM using S2a and GTP”, SA WG2 Meeting #104, S2-142364, July 7-11, 2014, Dublin, Ireland. Exemplary call flows for network-initiated and UE-initiated routing rule update procedure for S2a and S2b can be found in “IP flow mobility solutions for S2b (GTP)—UE-initiated and Network-initiated IP flow mobility”, SA WG2 Meeting #104, S2-142449, July 7-11, 2014, Dublin, Ireland.
3GPP is currently working on specifying a feature/mechanism for WLAN/3GPP Radio interworking in 3GPP Release-12, which improves operator control with relation to how a UE performs access selection and traffic steering between 3GPP and WLANs belonging to the operator or its partners, it may even be so that the mechanism can be used for other, non-operator, WLANs as well, even though this is not the main target. It has been agreed that for this mechanism the RAN provides assistance parameters that controls how the UE performs the access selection. The RAN assistance parameters are composed of three main components, namely threshold values, Offloading Preference Indicator, OPI, and WLAN identifiers. The following thresholds have been defined for LTE in TS 36.304, similar thresholds are also defined for the Universal Mobile Telecommunications System, UMTS:                ThreshServingOffloadWLAN, LowP—This specifies the Reference Signal Received Power, RSRP, threshold, e.g. in dBm, used by the UE for traffic steering to from E-UTRAN to WLAN.        ThreshServingOffloadWLAN, HighP—This specifies the RSRP threshold e.g. in dBm used by the UE for traffic steering from WLAN to E-UTRAN.        ThreshServingOffloadWLAN, LowQ—This specifies the RSRQ threshold in dB used by the UE for traffic steering from E-UTRAN to WLAN.        ThreshServingOffloadWLAN, HighQ—This specifies the Reference Signal Received Quality, RSRQ, threshold, e.g. in dB, used by the UE for traffic steering from WLAN to E-UTRAN.        ThreshChUtilWLAN, Low—This specifies the WLAN channel utilization (BSS load) threshold used by the UE for traffic steering from E-UTRAN to WLAN.        ThreshChUtilWLAN, High—This specifies the WLAN channel utilization (BSS load) threshold used by the UE for traffic steering from WLAN to E-UTRAN.        ThreshBackhRateDLWLAN, Low—This specifies the backhaul available downlink bandwidth threshold used by the UE for traffic steering from WLAN to E-UTRAN.        ThreshBackhRateDLWLAN, High—This specifies the backhaul available downlink bandwidth threshold used by the UE for traffic steering from E-UTRAN to WLAN.        ThreshBackhRateULWLAN, Low—This specifies the backhaul available uplink bandwidth threshold used by the UE for traffic steering from WLAN to E-UTRAN.        ThreshBackhRateULWLAN, High—This specifies the backhaul available uplink bandwidth threshold used by the UE for traffic steering from E-UTRAN to WLAN.        ThreshBeaconRSSIWLAN, Low—This specifies the Beacon Received Signal Strength Indicator, RSSI, threshold used by the UE for traffic steering from WLAN to E-UTRAN.        ThreshBeaconRSSIWLAN, High—This specifies the Beacon RSSI threshold used by the UE for traffic steering from E-UTRAN to WLAN.In addition a timer value is defined:        TsteeringWLAN—This specifies the timer value TsteeringWLAN during which the rules should be fulfilled before starting traffic steering between E-UTRAN and WLAN.        
The UE is also programmed with “RAN rules” that make use of these assistance parameters. There are “RAN rules” defined both for moving traffic from 3GPP access to WLAN access, and for moving traffic from WLAN access to 3GPP access. Examples of “RAN rules” are shown below:
Rule 1: The UE is to move traffic from E-UTRAN to WLAN if conditions 1 and 2 below are satisfied for a time interval TsteeringWLAN:                1. In the E-UTRAN serving cell: RSRPmeas<ThreshServingOffloadWLAN, LowP; or RSRQmeas<ThreshServingOffloadWLAN, LowQ;        2. In the target WLAN: ChannelUtilizationWLAN<ThreshChUtiWLAN, Low; and BackhaulRateDIWLAN>ThreshBackhRateDLWAN, High; and BackhaulRateUIWLAN>ThreshBackhRateULWLAN, High; and BeaconRSSI>ThreshBeaconRSSIWLAN, High;        
Rule 2: The UE moves traffic from WLAN to E-UTRAN if the following conditions 3 and 4 are satisfied for a time interval TsteeringWLAN:                3. In the source WLAN: ChannelUtilizationWLAN>ThreshChUtilWLAN, High; or BackhaulRateDIWLAN<ThreshBackhRateDLWLAN, Low; or BackhaulRateUIWLAN<ThreshBackhRateULWLAN, Low; or BeaconRSSI<ThreshBeaconRSSIWLAN, Low;        4. In the target E-UTRAN cell: RSRPmeas>ThreshServingOffloadWLAN, HighP: and RSRQmeas>ThreshServingOffloadWLAN, HighQ;Similar “RAN rules” are defined for UMTS.        
The thresholds values could be for example metrics such as 3GPP signal related metrics such as RSRP/RSRQ/RSCP/EcNo, WLAN signal related metrics such as RSSI, WLAN load/utilization, WLAN backhaul load/capacity, etc. RSCP stands for Received Signal Code Power. EcNo stands for Energy per chip over the Noise. One example of a RAN rule that uses the threshold value could be that the UE should move traffic to a WLAN if the RSRP is below the signaled RSRP threshold at the same time as the WLAN RSSI is above the signaled RSSI threshold. In a similar way RAN assistance parameters are used to control when the UE should steer traffic back from WLAN to 3GPP. The RAN rules/policies are specified in a 3GPP specification such as TS 36.304 v12.0.0 and/or TS 36.331 v12.1.0.
In addition to providing the RAN Assistance Parameters from the RAN to the UE, the network also informs the UE about what PDN Connections are offloadable to WLAN and what PDN Connections are not offloadable and should remain in 3GPP access. For example, an operator may desire that the PDN Connection for IP-based Multimedia Services, IMS, (Voice over LTE) remains in 3GPP access while the PDN Connection for general Internet access may be moved to WLAN access. This indication is hereafter referred to as an “offloadability” indication. In the solution specified by 3GPP in rel-12, this “offloadability” indication is provided to the UE via Non-Access Stratum, NAS, signaling from the MME or SGSN to the UE.
The RAN rules are applied by the UE in such a way that when the RAN rule for moving traffic to WLAN is fulfilled, the UE moves all PDN Connections marked as “offloadable” to WLAN while any non-offloadable PDN Connections stays on 3GPP access. When the RAN rule for moving traffic to 3GPP access is fulfilled, the UE moves the PDN Connections active on WLAN to 3GPP access. A limitation of the rel-12 solution is that only PDN Connection level mobility is supported, i.e. the UE can move the PDN Connection between WLAN and 3GPP access, controlled by the RAN rules. However, the RAN cannot control IP flow mobility as being worked on in the rel-13 IFOM work item.
With the above mechanism it is likely not wanted, or maybe not even feasible, that the UE considers any WLAN when deciding where to steer traffic. For example, it may not be feasible that the UE uses this mechanism to decide to steer traffic to a WLAN not belonging to the operator. Hence it has been proposed that the RAN should also indicate to the UE which WLANs the mechanism should be applied for by sending WLAN identifiers. The RAN may also provide additional parameters which are used in Access Network Discovery and Selection Function, ANDSF, policies. One proposed parameter is the OPI. One possibility for OPI is that it is compared to a threshold in the ANDSF policy to trigger different actions, another possibility is that OPI is used as a pointer to point, and select, different parts of the ANDSF policy which would then be used by the terminal, i.e. the UE.
The RAN assistance parameters, i.e. thresholds, WLAN identifiers, OPI provided by RAN, may be provided with dedicated signaling and/or broadcast signaling. Dedicated parameters can only be sent to the UE when having a valid RRC connection to the 3GPP RAN. A UE which has received dedicated parameters applies dedicated parameters; otherwise the UE applies the broadcast parameters. If no RRC connection is established between the UE and the RAN, the UE cannot receive dedicated parameters. In 3GPP, it has been agreed that ANDSF should be enhanced for release-12 to use the thresholds and OPI parameters that are communicated by the RAN to the UE. More information on the ANDSF enhancements to support OPI and thresholds can be found in TS 23.402. If enhanced and valid ANDSF policies are provided to the UE, the UE will use the ANDSF policies instead of the RAN rules/policies (i.e. ANDSF has precedence). More detailed description for when RAN rules/policies are used and when ANDSF policies are used can be found in TS 23.402.
When performing handover between 3GPP access and WLAN, the existing RAN level integration method only supports mobility on a per-APN, or rather per PDN Connection, basis. The RAN Assistance Parameters, and in particular the thresholds, apply to all offloadable traffic of a UE. If the RAN rules for moving traffic to WLAN are fulfilled, the UE moves all offloadable PDN Connections to WLAN. Similarly, when RAN rules for moving traffic to 3GPP are fulfilled, the UE moves all PDN Connections active on WLAN to 3GPP. If IP Flow Mobility (IFOM) e.g. for S2a/S2b is supported by the UE and the network, there is no possibility to utilize the RAN solution together with the more fine-grained mobility support provided by IFOM.